fix: Do not report a permanent data source failure as fatal - #52
Open
kinyoklion wants to merge 1 commit into
Open
fix: Do not report a permanent data source failure as fatal#52kinyoklion wants to merge 1 commit into
kinyoklion wants to merge 1 commit into
Conversation
Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>
Contributor
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
Contributor
|
@cursor review |
kinyoklion
marked this pull request as ready for review
August 20, 2026 22:02
kinyoklion
added a commit
to launchdarkly/openfeature-dotnet-server
that referenced
this pull request
Aug 20, 2026
A permanently shut down data source set the provider's internal status to `Fatal`, even though the LaunchDarkly client can keep evaluating flags from the data it already has. - `DataSourceState.Off` now sets `ProviderStatus.Error`, matching `InitializeAsync` and the Java provider - No user-visible change today: both `Error` and `Fatal` emit `ProviderEventTypes.ProviderError`, and the OpenFeature SDK derives provider status from events, so nothing consumed the `Fatal` value - Adds an integration test asserting evaluations still succeed through the OpenFeature client after the data source goes off @cursor review <details> <summary>Implementation details</summary> **Why change it if nothing consumes it** `Fatal` is the OpenFeature status that means "flag resolution cannot happen"; the SDK short-circuits to call-site defaults in that state. That is wrong for LaunchDarkly, since a dead stream (for example a 401 on an established connection) leaves the in-memory store fully usable. The value was only saved from causing that behavior because `StatusProvider` maps both `Error` and `Fatal` to a `ProviderError` event. Leaving the misleading value in place invites a regression the next time this status is wired to anything. The sibling fix in the Python provider (launchdarkly/openfeature-python-server#52) does have user-visible impact, because that provider emits a fatal event directly. **Alternatives considered** Emitting `Stale` for `Off` was rejected: the failure is not recoverable without a new client, so consumers should see an error. **Testing** `dotnet test test/LaunchDarkly.OpenFeature.ServerProvider.Tests -f net8.0` — 60 tests pass, including the new `ItCanEvaluateFlagsAfterTheDataSourceHasBeenShutdown`. Note that this test also passes on `main`, for the event-mapping reason above; it is a guard, not a reproduction. No visual preview applies — this is a server-side provider change. </details> Link to Devin session: https://app.devin.ai/sessions/0c452d209ec54b068ba120b4c92b8f6c Requested by: @kinyoklion <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Overview** > When the LaunchDarkly data source shuts down permanently (`DataSourceState.Off`), the provider now reports **`ProviderStatus.Error`** instead of **`ProviderStatus.Fatal`**, because the LD client can still evaluate flags from in-memory data. > > This aligns `StatusChangeHandler` with **`InitializeAsync`** (which already used `Error` for `Off`) and with the Java provider. **`StatusProvider`** still maps both `Error` and `Fatal` to `ProviderEventTypes.ProviderError`, so emitted events are unchanged today; the fix avoids mislabeling the internal status if OpenFeature later treats `Fatal` as “cannot resolve flags.” > > A new integration test **`ItCanEvaluateFlagsAfterTheDataSourceHasBeenShutdown`** verifies boolean evaluation through the OpenFeature client after the mocked data source transitions to `Off`. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit fbe6159. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A permanent data source failure no longer puts the provider into the OpenFeature
FATALstate, so the OpenFeature client keeps evaluating against the flag data the LaunchDarkly client already has.DataSourceState.OFFnow emitsErrorCode.GENERALinstead ofErrorCode.PROVIDER_FATALERRORRequirements
Implementation details
Related issues
#49 — during an outage, a
401on an already-established stream took the data source toOFFand OpenFeature evaluations started returning call-site defaults even though the LaunchDarkly client still had valid flag data.Describe the solution you've provided
The OpenFeature Python SDK short-circuits evaluation when the provider status is
FATAL:That means the provider is never asked to evaluate and the call-site default is returned.
PROVIDER_FATALis what moves the provider into that status, so reporting a permanent data source failure that way discards flag data the LaunchDarkly client can still serve.ErrorCode.GENERALkeeps the provider inERROR, which still surfaces the failure through provider events andget_provider_status()while leaving evaluation intact.Describe alternatives you've considered
Leaving the state fatal only when the client never initialized was considered. It adds state tracking to the provider for little benefit: a client that never initialized has no flag data, so evaluations already fall back to defaults with a
PROVIDER_NOT_READY/ERRORreason, and theERRORstatus carries the same signal to anything watching provider events.Testing
Added
test_evaluations_continue_after_the_data_source_permanently_fails, backed by a newInitializedThenFailingDataSourcefixture that initializes with flag data, goesVALID, then transitions toOFFwith a401. The test asserts the provider status isERRORand that the cached flag still evaluates to its real value rather than the call-site default.Link to Devin session: https://app.devin.ai/sessions/0c452d209ec54b068ba120b4c92b8f6c
Requested by: @kinyoklion
Note
Overview
Stops treating a permanent data source failure (
DataSourceState.OFF) as OpenFeaturePROVIDER_FATAL, so evaluations keep using cached LaunchDarkly flag data instead of being short-circuited to call-site defaults.__handle_data_source_statusnow emitsErrorCode.GENERAL, leaving the provider inERRORwhile still surfacing the failure. A new test initializes flags, then fails the data source with a 401, and asserts status isERRORand the cached flag still evaluates correctly.Reviewed by Cursor Bugbot for commit e0fea34. Bugbot is set up for automated code reviews on this repo. Configure here.